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FIELD OF THE INVENTION 

The present invention relates to a computerized system for devising a training scheme for a 
sports person. 
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BACKGROUND OF THE INVENTION 

It is a problem for an amateur sports person to select a training scheme appropriate to his/her 
sport. It is a fact that success in sports is highly related to individual body measurements. For 
instance, it can be seen that the anthropometrical differences between sprinters are far less than 
between sprinters and the general public. It is suggested that there is a specific idealized 
anthropometric and physiological profile for the sport of sprinting. There will be different idealized 
physiological profiles for different sports. General training schemes are widely available, but it is 
not easy for the amateur sports person to arrive at a training scheme suitable both for his/her sport 
and also his/her current physiological profile. The present invention aims to address this. 
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BRIEF SUMMARY OF THE INVENTION 

In a first aspect, the present invention provides a training system comprising: a database 
comprising information regarding the relevance of different physical activities to training categories; 
and a server for transferring information between a user and the database. 
5 In a second aspect, the present invention provides a training system comprising: a database 

comprising information regarding the nutritional content of different foodstuffs; and a server for 
transferring information between a user and the database. 

In a third aspect, the present invention provides a training system comprising: a database for 
storing information regarding a goal of a user; and a server for transferring information between a 
10 user and the database. 

In a fourth aspect, the present invention provides a training system comprising: a database 
for storing information regarding an injury sustained by a user; and a server for transferring 
information between a user and the database. 

In a fifth aspect, the present invention provides a computerized system for devising a training 
15 scheme for a sports person comprising: first computer means for processing data, which has a 
database which stores for each of a plurality of sports a record of an idealized physiological profile; 
wherein: each sports person using the system inputs a selection of a sport and, in response to 
enquiries generated by the first computer means, information concerning his/her physiological 
profile; and the first computer means compares the physiological profile input by each sports person 
20 with the idealized physiological profile for the relevant sport and from this comparison formulates a 
training regime which is relayed to the sports person. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows a schematic illustration of a computerized training system; 

Figure 2 shows an introductory web page as seen by a user of the system; 

Figure 3 shows a fitness status assessment web page, for updating information, as seen by the 

user; 

Figure 4 shows a fitness status assessment web page, for displaying an assessment of the 
user's fitness, as seen by the user; 

Figure 5 shows a web page for setting goals, as seen by the user; 

Figure 6 shows a web page for setting outcome goals, as seen by the user; 

Figure 7 shows a graphical representation of what the user considers to be his strengths and 
weaknesses, as seen by the user; 

Figure 8 shows a goal completion web page, as seen by the user; 

Figure 9 shows a goal history web page, as seen by the user; 

Figure 10 shows an activity assessment web page, as seen by the user; 

Figure 1 1 shows a detailed activity entry web page, as seen by the user, for allowing the user 
to enter detailed activity information; 

Figure 12 shows an activity assessment overview web page, as seen by the user, displaying*' 
an overview of the user's recent physical activity; 

Figure 13 shows a detailed activity assessment web page, as seen by the user, displaying a 
detailed analysis of the user's activities; 

Figure 14 shows a diet web page, as seen by the user, for entering dietary information; 

Figure 15 shows detailed diet web page, as seen by the user, for entering detailed dietary 
information; 

Figure 16 shows a nutrition assessment web page, as seen by the user, which provides an 
assessment of the suitability of the user's diet with regard to the number of calories deemed to be 
required by the user; 

Figure 17 shows a web page, as seen by the user, that suggests appropriate changes, if 
deemed necessary, to the user's diet; 

Figure 1 8 shows a web page, as seen by the user, that allows the user to indicate, at a coarse 
level, his intended training activity for the next seven days, and allows the user to cause a proposed 
training schedule, tailored to his needs, to be generated; 
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Figure 19 shows a web page, as seen by the user, that allows the user to refine the training 
schedule generated; 

Figure 20 shows a web page, as seen by the user, that allows the user to enter information 
regarding injuries that he has sustained; 
5 Figure 2 1 shows a web page, as seen by the user, that allows the user to enter more detailed 

information regarding injuries that he has sustained; 

Figures 22a to 22d show the database structure of a database of the training system, with 
Figure 22 showing how Figures 22a to 22d should be assembled; and 

Figure 23 shows a schematic illustration of a second embodiment of a computerized training 

10 system. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Figure 1 is a schematic illustration of an embodiment 100 of the training system. 

The training system allows a user to enter information concerning: (i) "goals" (a goal may 
be, for example, winning a national sports competition, or losing weight), (ii) details of his current 
5 height, weight and fitness, (iii) details of injuries he has sustained, (iv) details of his physical activity 
during recent days, and (v) details of his food intake over recent days. 

The system processes the information entered by the user and outputs information to the user 
concerning: i) an assessment of the suitability of his diet, (ii) an assessment of his fitness relative to 
the fitness of his assumed peers, and (iii) a suggested training program. 
1 0 The system comprises a server 101 which is connected to a personal computer (PC) 1 02 by a 

communications link 1 12. In this embodiment the server 101 implements a relational database 1 10 
and runs software that implements the training system. In this embodiment of the system the 
database 110 is shown as being a constituent part of the server 101 although in alterative 
embodiments the database 110 may be separate from the server 101 . 
1 5 The PC 1 02 is operated by a user of the system and allows the user to send data to the server 

101 and to receive data from the server 101 . Data received by the server 101 from the PC 102 can 
be stored on a hard disk (not shown). 

The server 101 is also connected by a communications link 1 13 to a payment server 103. A 
user pays to use the system 100 by entering their credit card details at the PC 102. The credit card 
20 details are then encrypted by known means and transferred over the communications link 1 1 2 to the 
server 101 and then transferred from the server 101 over the telecommunications link 1 13 to the 
payment server 103. 

In this embodiment the communications links 1 12, 1 13 both comprise the internet. When a 
user contacts the server 101, his PC 102 requests an internet web page from the server 101. The 

25 server 1 0 1 then generates a web page and transfers the web page over the communication link 11 2 to 
the PC 102 for display. The PC 102 uses suitable software such as Internet Explorer or Mozilla to 
display the web page. In this embodiment the server 102 uses "Flash" software from the company 
Macromedia, Inc. to embed multimedia objects in the web page. The embedded objects in turn are 
able to prompt the user to enter information, and are operable to cause the PC 102 to transfer the 

30 entered information to the server 101. The user can use different parts of the system 100 by 
selecting icons on the web pages, for example by using a pointer device such as a mouse and 
"clicking" the icon. In response to the icon selected, the server 101 then generates the appropriate 
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web page. On some web pages generated by the server 101, the web pages contain "buttons" instead 
of icons. A button is not a physical button but is a region of the web page that can be selected by the 
user using a pointing device such as a computer mouse. Unlike icons, buttons do not graphically 
represent their function. 

5 In this embodiment the database is implemented using the "MySQL" software package 

available from the company MySQL.com. The majority of the training system 1 00 is implemented 
using the Java programming language available from the company Sun. Thus the Flash software 
provides a graphical user interface for the Java software, while the MySQL implements the database 
110. 

10 CREATING AN ACCOUNT 

To create an account (also known as "registering") with the server 101, the user asks the 
server 101 to establish a new account for him. The server 101 prompts the user, via Flash objects 
embedded in a web page, for relevant information such as: (i) his first name, (ii) his surname, (iii) 
his age, (iv) his email address, (v) his postal address, (vi) a password which he can use on future 
15 occasions to authenticate himself to the server 101, and (vii) his credit card details. 

The server 101 passes the credit card details to the payment server 103. . If his credit card 
details are valid and are successfully processed by the payment server 103 then the payment server 
1 03 informs the server 101 that his account can be activated. Once his account has been activated by 
the server 1 0 1 , the user can then authenticate himself to the system 1 00 using his password and can 
20 begin to use the features provided by the system 100. 
INTRODUCTORY WEB PAGE 

Figure 2 shows a web page 200 which is initially seen by the user whenever he uses his PC 
102 to connect to the server 101. The web page 200 has seven regions 201-207 which act as icons 
and allow the user to select a particular aspect of the system 100. 
25 In this embodiment, the system 100 provides a training system for ice skaters and thus the 

regions 201-207 are customized accordingly. The seven regions are: nutrition 201, competitions 
202, fitness 203, ice training 204, goals 205, injury 206 and updates 207. 

The nutrition region 201 allows the user to enter information concerning his diet. The server 
101 assesses the user's diet with regard to the user's activity level and injuries and provides an 
30 indication of whether the diet is meeting or exceeding the user's requirements. The competitions 
region 202 reminds the user of forthcoming competitions and allows the user to enter information 
concerning competitions. The fitness region 203 allows the user to enter information concerning his 
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current fitness levels with regard to various indications of fitness. The ice region 204 allows the user 
to enter information concerning his skill and training levels on ice. The goal setting region 205 
allows the user to enter "goals" that the user wishes to achieve. The injury region 206 allows the 
user to enter information concerning injuries that the user may inadvertently have sustained. The 
5 updates region 207 prompts the user to enter more recent information should the information 
concerning, for example, his fitness become out of date. 
HEIGHT, WEIGHT AND DETAILED FITNESS INFORMATION 

Once the user's account is activated, the server 101 still needs to obtain further information 
from the user concerning: (i) basic physical attributes such as the user's height and weight and (ii) 
1 0 detailed fitness information for the user. 

The fitness region 203 displays a text caption that informs the user that this information is 
required by the server 101. The user then selects the fitness region 203 . In response, the server 1 0 1 
prompts the user to enter the (i) basic physical attributes and (ii) detailed fitness information. 

Firstly, the server 101 prompts the user to enter his height and weight in imperial units, i.e. 
1 5 feet and inches for height and stones and pounds for weight. 

Secondly, the server 101 prompts the user to enter the following detailed fitness information: 
(i) the number of pushups that the user can complete in 60 seconds ( 1 minute), (ii) number of situps 
in one minute, (iii) vertical jump height, (iv) long jump distance, (v) sit and reach distance, (vi) time 
to run a distance of one mile ( 1 ,609 meters), and (vii) number of "shuttles". The user needs to have 
20 performed the seven tests before he can enter the information. Of course, the user does not need to 
have performed the tests before creating an account; the user can create his account, perform the 
seven tests and then log in to the server 101 at a later time and/or date in order to enter the detailed 
fitness information. 

Pushups and situps measure the core stability of the user. The core stability is a measure of 
25 the strength of the user's "core" muscles. The core muscles include the abdominal and lower back 

muscles (i.e. trunk and torso muscles). Core stability is one measure of the fitness of the user. 

Vertical jump height and long jump distance measure the short-term "explosive" strength of the user. 

Sit and reach distance measures the flexibility of the lower back and hamstrings of the user. The 

one mile run time and the shuttles test both give an indication of the cardiovascular endurance of the 
30 user. As those skilled in the art will appreciate, the "shuttles" test measures cardiovascular 

endurance by requiring the user to complete a 20m distance every time an audible "bleep" is 
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sounded. Every 3 minutes, the rate of the bleeps increases. The test continues until the user can no 

longer complete the 20m distance between consecutive bleeps. 

UPDATES 

The server 101 also records the calendar date on which each of nine categories of height, 
5 weight and fitness information is provided by the user (i.e. seven for fitness together with height and 
weight). This allows the server 101 to prompt the user to enter more recent information when there 
is a risk that the current information might be out of date. The updates region 207 as shown at 
Figure 2 indicates that more recent height and weight information is required. However, the 
following example concerns the detailed fitness information. 

10 Figure 3 shows an example of a web page 300 as seen by the user. The web page 300 

includes a region 301 that lists the seven categories of detailed fitness information. The height and 
weight categories are not shown by Figure 3. As shown, the region 301 indicates that the updated 
information regarding the user's sit and reach ability is required now (i.e. the region 301 displays 
"Now"), arid indicates that updated information regarding the vertical jump and the long jump will 

15 be required in 7 days' time (thus the region 301 displays "7 days" for these two categories). Of 
course, the user's new sit and reach ability may actually be the same as his previous sit and reach 
ability. : 

For each of the nine categories, the server 101 stores the date of the most recent information 
and compares this with the current date. The result of the comparison is used by the server 101 to 

20 give the user advance warning of when more recent information will be required. If the result of the 
comparison exceeds a predetermined threshold, i.e., if a category of information is too old, then the 
server 101 prompts the user for more recent information. In this embodiment, for each of the 9 
different categories, the server 101 has a respective threshold to determine the maximum age of the 
measurement. For example, for the vertical jump and long jump strength categories, more recent 

25 information is requested if the current information stored is more than 7 days out of date. For the 
one mile run and shuttle test cardiovascular categories, more recent information is requested in the 
current information is more than 33 and 36 days old, respectively. The cardiovascular ability of 
most users will improve more slowly than their strength and thus less frequent updates are required 
for the cardiovascular categories. Note that although the user is prompted to enter more recent 

30 information when a category has exceeded its respective threshold, the user does not have to wait 
until a category is out of date but can enter more recent information at any time. 
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In this embodiment, not only can each of the nine categories have a respective threshold, but 
the threshold can be different for different users. For example, height (and weight) information is 
required more frequently when the user is in his/her teens than when fully grown. Thus the 
thresholds can be different not only for different users but can also vary according to the age or 
5 fitness of the user. 

Adolescents have growth spurts which provide both training opportunities and also present 
risks. During a growth spurt, the bones grow and the ligaments loosen. In this embodiment, height 
information is required of males at the following intervals: 

ages 8- 1 1 every 4 weeks, 
1 0 ages 11-17 every 2 weeks, 

ages 17-21 every 4 weeks, and 

ages 2 1 + every 6 months . 

Height information is required of females at the following intervals: 
ages 8-10 every 4 weeks, 
15 ages 10-14 every 2 weeks, 

ages 14-18 every 4 weeks, and 
ages 18+ every 6 months. 

Once the height, weight and fitness information has been provided to the server 101 by the 
user, the server 101 can use the information to assess the fitness of the user. This is discussed in 

20 more detail below. 

FITNESS STATUS ASSESSMENT 

Once the server 101 has received the fitness information from the user, the user can select a 
fitness status assessment. Figure 4 shows an example of a web page 400 illustrating a fitness status 
assessment 401 . In this embodiment the fitness status assessment is a chart 401 that shows the user's 

25 current fitness levels compared to those of his nominal peers. As shown, for each of the seven 
categories of detailed fitness information, a respective segment of the chart is displayed, the radial 
spacing from the ??? center indicating the user's fitness level compared to that of his nominal peers. 
For each category, the user's fitness is rated as either excellent, good, average or poor. For the user 
whose fitness level is shown at Figure 4 has excellent fitness levels for mile run, sit and reach, long 

30 jump, vertical jump and pushups, and good levels for shuttles and situps. The color of the associated 
segment is selected on the basis of the fitness rating. The chart 401 provides a user with an easily 
interpretable fitness assessment. 
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Note that the user's fitness is compared to his nominal peers, not against other users of the 
system. When a user creates an account, he is required to enter information indicating the skill level 
at which he skates. For example, the user may indicate that he skates at a "county championship" 
skill level. The system compares the user's height, age and skating skill level with information 
5 stored in the database 1 1 0 of the server 101. 

In this embodiment, the stored information summarizes the fitness levels of skaters at various 
heights, ages and skill levels, as determined by measuring the fitness of real skaters. The server 101 
interpolates and extrapolates the stored information in order to determine the fitness level expected 
of the user. Note that in an alternative embodiment, the server 101 may store a mathematical 
10 formula, instead of stored information, in order to allow the user's height, age and skill level to be 
related to the fitness level expected of him. . 

Once the server 101 has compared the user's actual fitness level with the fitness level 
expected of him, the fitness assessment results are displayed as the pie chart 401. 
GOALS - SETTING 

15 By selecting the goal setting region 205 of Figure 2, the user can indicate to the server 101 

that he wishes to enter, or review, information concerning his goals. In response, the server 102 

causes a web page to be displayed on the user's PC. 

Figure 5 shows an example web page 500 as seen the user. The web page 500 includes 

sections relating to "outcome" goals 501, "long term" goals 502 and "dream" goals 503. Outcome 
20 goals 501 are relatively short term goals. Dream goals 503 represent the ultimate ambition of the 

user, for example to win a regional or a national competition. 

The inventors of the present application have realized that for a user to successfully compete 

at his desired level, it is not sufficient for the user to train only with regard to his physical fitness. 

Rather, to ensure that the user competes successfully, it is also necessary to ensure that the user 
25 develops an appropriate mental attitude so that under the pressure of competition conditions he 

performs at the level he has achieved during training. 

The dream goal section 501 allows the user to specify what he regards as his dream goals. 

Depending on the ability of the ice skater, his dream goal might be winning a regional championship 

or winning an Olympic competition. In this embodiment the dream goal section does not provide a 
30 selection of pre-prepared options but requires the user to consider his ambitions and to express his 

ambitions in his own words. 
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Once the user has formulated his dream goal(s), the user can use the long term goal section 
502 to enter long term goals that will provide a path to achieve his dream goal. For example, the 
user might consider that an important stepping-stone to achieving his dream goal is that of winning a 
regional ice skating competition. Accordingly, the user enters this into the long term goal section 
5 502. 

Finally, the user can use the outcome goal section 501 to enter goals that have definite 
outcomes. The outcome goals are intended to be relatively short term and thus the server 101 allows 
the user to enter goals for the next 3 months, the next 6 months and the next 12 months. Although a 
user can enter his goals in any order into the dream goal section 503, long term goal section 502 and 

10 outcome goal section 501, it is intended that the user enter his goals in the above order so that he 
derives maximum benefit from this aspect of the system. 

Figure 6 shows a web page 600 that enables the user to set his outcome goals. The web page 
600 is displayed when the user selects a "Details" button 5 10 on the web page 500. As shown, the 
web page 600 allows the user to select outcome goals from a drop-down box 601. The user may 

1 5 , enter up to three outcome goals for a 3 month period. Examples of outcome goals are (i) finishing in 
the top ten rankings for an event, or (ii) beating a certain competitor at an event. 

The user can also the web page 600 to enter the dates of competitions. The dates entered of 
such competitions are stored by the server 1 0 1 in the database 1 1 0. When a competition approaches 
(for example is two weeks away) the server 101 "tapers" an exercise regime for the user, thus 

20 ensuring that the user is in peak condition for the competition. The tapering is discussed in more 
detail further below. 

The process of entering his outcome goals into the goal sections 501-503 facilitates the user 
to become aware of how he can use outcome goals to achieve his dream goal. Once the user has 
entered goals into the goal sections 501-503, he will be ready to use a "factors" section 504 and a 
25 physical strengths & weaknesses section 505 of the web page 500. The factors section 504 and the 
physical strengths & weaknesses section 505 together form "process goals". Process goals are well 
defined; achievement of the process goals is intended to provide the means by which the user will 
achieve his outcome, long term and dream goals. 

The factors section 504 allows the user to enter what he regards as key technical and mental 
30 factors. In this embodiment the system is suitable for an ice skater. Therefore, the factors section 
504 offers a range of predetermined options that are suitable for the technical factors that affect an 
ice skater. As shown at the factors section 504, the user has selected the following technical factors: 
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(i) clean edges, (ii) high jumps and (iii) centered spins. The user has also selected the following 
mental factors: (i) maintaining concentration throughout the routine, (ii) coping with mistakes and 
(iii) coping with the pressure. Note that only the first of these mental factors is shown at the factors 
section 504. 

5 The physical strengths & weaknesses section 505 allows the user to enter what he regards as 

key physical strengths and weaknesses that he needs to develop. The physical strengths and 
weaknesses section 505 allows the user to select from predetermined options. As shown at the 
physical strengths and weaknesses section 505, the user has selected cardio-vascular and flexibility 
as his weaknesses. Note that the view of the physical strengths and weaknesses section 505 shown 
10 at Figure 5 does not show any strengths. 

Once the user has entered his strengths and weaknesses into the factors section 504 and the 
physical strengths & weaknesses section 505, he can select an button 506 to display graphical 
representation of his strengths and weaknesses. 
GOALS - GRAPH 

1 5 Figure 7 shows an example web page 700 as seen by the user. In this embodiment, the web 

page 700 includes a chart 70 1 that allows the user to readily interpret his strengths and weaknesses. 
The chart 701 has segments corresponding to the following technical factors: (i) double flips, (ii) 
triple toe, (iii) clean edges, (iv) high jumps, (v) centered spins; the following mental factors: (vi) 
maintaining concentration throughout the routine, (vii) coping with mistakes, (viii) coping with the 

20 pressure; and the following physical strengths and weaknesses: (ix) core stability, (x) jumping 
power, (xi) cardiovascular and (xii) flexibility. Note that although the pie chart 701 is shown as 
having twelve segments, the actual number of segments depends on the number of technical and 
mental factors and physical strengths and weaknesses entered into the web page 500. 
GOALS - COMPLETION AND HISTORY 

25 Figure 8 shows a goal completion web page 800, as seen by the user. The web page 800 is 

displayed at the user's PC 102 when the user selects an appropriate icon (not shown) from the web 
page 500. The web page 800 allows the user to review his goals and to indicate to the server 101 
when goals have been completed. Thus the system 100 provides a goal orientated method to 
facilitate the user to understand ways in which he can improve his performance. 

30 The web page 800 displays goals that have not been completed at a region 801 and displays 

goals that have been completed at a region 802. A description of a goal that has been selected by the 
user is displayed at a region 803. Note that Figure 8 does not actually show any goals. 
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A user can readily use the web page 800 to inform the server 1 0 1 of the goals that have been 
completed. For example, if a goal has been completed then the user selects the goal and then selects 
a button 805 which causes the server 101 to move the goal from an "incomplete" section of the 
database 1 10 to a "completed" section of the database 1 10. The web page 800 is then updated. It 
5 will be recalled that the server 101 implements a database 1 10. Goals that have not been completed 
are stored in a section of the database 110 allocated for incomplete goals. When the user has 
completed the goal, he uses the button 805 to cause the server 101 to update the database 1 10 and 
move the goal to the section of the database 110 allocated for completed goals. 

Figure 9 shows a goal history web page 900. The web page 900 helps the user to keep track 

1 0 of his goals. A session date field 90 1 allows the user to enter a session date, in this case 1 -Dec-2003 . 
In response, the server 101 interrogates the database 1 10 for goals relevant to the session date and 
causes an updated web page 900 to be displayed at the user's PC 102. The updated web page 900 
displays the relevant goals in a display field 902. Note that in Figure 9, only a completed long term 
goal is shown in the display field 902. A goal category field 903 allows the user to select a particular 

15 category of goals to be displayed in the display field 902. As shown by Figure 9, the user has 
selected long term goals in the field 903 and thus only long term goals having relevant dates are 
displayed in the display field 902. 
ACTIVITY ASSESSMENT 

The fitness region 203 of the web page 200 allows the user to cause the server 101 to .display 

20 an activity assessment web page 1000 on the user's PC 102. Figure 10 shows the activity 
assessment web page 1000 as seen by the user. The activity assessment web page 1000 allows the 
user to inform the server 101 of the physical activities that the user has performed recently. In 
response, the server 101 calculates the energy expenditure of the user and also calculates the 
suitability of the user's physical activities to the user's training program. 

25 The activity assessment web page 1000 shows a field 1001 which, in this embodiment, 

displays the most recent seven days. (The server 101 in this embodiment includes a real time clock 
so that the server 101 always knows the current calendar date.) The field 1001 has seven buttons 
1002 which the user can select to view and/or edit the physical activities for the respective day. The 
field 1001 also has seven status indicators 1003 which inform the user when physical activity 

30 information as been entered for the respective day. In this embodiment, the server 101 requires 
information for at least five of the seven days. This ensures that the information is representative of 
the previous seven days. Note that if the user enters information for all seven days then the user's 
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energy expenditure the suitability of the user's physical activities can be determined directly. On the 
other hand, if the user enters information for, for example, just five of the seven days then the 
information for the five days is multiplied by 7/5 (1 .4) in order to scale the information to a seven 
day period. 

When the user selects one of the buttons 1 002 the server 1 02 causes a detailed activity 
assessment web page 1 100 to be displayed on the user's PC 102. Figure 1 1 shows an example of a 
detailed activity entry web page 1 1 00, in this case for the date 6 January 2004. The web page 1 1 00 
includes two pull down menus 1101 that the user can use to select an activity type. In Figure 1 1 , the 
activity type selected is "walking the dog". The user then uses a "duration" pull down menu 1 1 02 to 
indicate to the server 101 the duration of the activity. In Figure 1 1, the duration selected for the 
activity is one hour. Finally, the user uses a button 1 103 to add the activity to a list 1 104. The list 
1 104 lists all the activities entered for the particular day. 
ENERGY EXPENDITURE 

On the basis of the activity information entered, the server 101 calculates the energy 
expenditure for the day (i.e. 9 for the 24 hour period of 6 January 2004). The server 101 calculates 
the total energy expenditure for the day by adding up the energy expenditure caused by all the 
separate activities of the day. For the day shown at Figure 1 1, the user has entered the activities of 
"walking the dog" and "baseball." For each of these activities, the server 101 consults the database 
110 and determines the energy expenditure on the basis of: (i) the type of activity (e.g., baseball), 
(ii) the duration of the activity (e.g., 1 hour), and (iii) the height, weight, age and gender of the user. 

For the remaining time of the day, in this case 22 hours, the server 101 uses "Basal Metabolic 
Rate" to determine the energy expenditure. As those skilled in the art will appreciate, there are 
various different formulae for calculating the basal metabolic rate of an individual but the formulae 
generally relate the individual's height, weight, age and gender to the energy expenditure. For 
example, according to one formula, a 30 year old male who is 1 .72m tall and weighs 70kg will have 
a basal metabolic rate of 1680 kilo-calories for a 24 hour period (where each kilo-calorie is 
equivalent to 4184 joules of energy). Thus he will require 70 kilo-calories an hour if he is resting or 
asleep. For the example shown at Figure 1 1 , the user is deemed to be asleep or resting for 22 hours 
of the day and active, to different degrees, for the remaining two hours. When walking the dog, the 
user will expend energy at a greater rate, 224kCal per hour as shown at the list 1 105. Similarly, the 
user will expend 449kCal per hour when playing baseball. 
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When the user has used the web page 1 100 to enter his activities for at least 5 of the most 
recent 7 days, the server 101 calculates his average daily energy expenditure and displays this at a 
field 1201 as part of an activity assessment overview web page 1200, shown at Figure 12. The web 
page 1200 also includes a field 1204 which displays the average daily time that the user has spent 
5 sleeping, training for ice skating and fitness {i.e., non-ice skating training). 

The user may use a button 1203 to view a detailed assessment of the relevance of the past 
seven days' activities to his training requirements, as shown at Figure 13. 
DETAILED ACTIVITY ASSESSMENT 

Figure 1 3 shows a detailed activity assessment web page 1 300, as seen by the user. The web 
1 0 page 1 300 displays a field 1301 that provides the user with a detailed analysis of the user's physical 
exercise during the preceding seven days. 

As shown, in this embodiment the field 1301 displays detailed information for each of six 
training areas: (i) flexibility, (ii) cardio-vascular, (iii) local muscular endurance, (iv) core stability, 
(v) lower body strength and upper body strength (vi). Local muscular endurance is the ability of a 
15 single muscle to perform sustained work. 

Each of the training areas relates to a type of exercise that is important to ice skaters. The 
field 1301 shown at Figure 1 3 displays "actual" and "target" percentages for each of the six training 
areas although note that, for the web page 1 300, all of the actual percentages happen to be 0%. The 
actual and target percentages are normalized to the training needs of the user, taking into account the 
20 skill level of the user. 

For example, in this embodiment the database 110 stores predetermined information 
indicating that a 30 year old male user, who skates at an advanced level, should be performing 6 
hours per week of "normalized" lower body strength exercises. The user can achieve the 6 hours per 
week either by performing physical exercises such as squat thrusts that are almost 100% appropriate 
25 to lower body strength, or could perform 12 hours per week of exercises such as baseball that is 50% 
appropriate to lower body strength. Conversely, while squat thrusts are an excellent way of 
improving lower body strength, they do not appreciably develop other training areas such as 
flexibility. On the other hand, baseball provides better all-round training than squat thrusts. 

Based on the activity data entered by the user to the web page 1 100 for each of the days, the 
30 server 1 0 1 uses the database 1 1 0 to assess how relevant the activities are to the training needs of, in 
this embodiment, an ice skater. The database 1 1 0 stores predetermined data values which have been 
empirically found to give good results when training ice skaters. Here, it has been determined that a 
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good training program for an ice skater should devote, for example, 10% of the training effort to 
flexibility, 15% to cardio-vascular, 10% to local muscle endurance, 25% to core stability, 35% to 
lower body strength and 5% to upper body strength, as shown by the field 1301. 

Note that in this embodiment the percentages displayed at the field 1301 are normalized to 
5 the requirements of the user. Thus for a user who skates at an intermediate level, 3 hours of squat 
thrusts every week would achieve 100% of his target lower body strength physical activity. 
Conversely, a user who skates at an Olympic level would need to perform 6 hours of squat thrusts 
every week to achieve 100% of his target lower body strength physical activity. Thus different 
physical activities are weighted for their relevance to the six training areas displayed at the field 
10 1301 . The weights are stored in the database 110. 

As will be described later in more detail, the predetermined information stored in the 
database 1 1 0 concerning the physical activity requirements for the six training areas can be modified 
by the server 101 before being used as the target percentages in the field 1301. As those skilled in 
the art will appreciate, sportsmen/sportswomen typically "taper off 5 their training regimes before a 
15 major competition. This is to reduce the risk of sustaining injuries through training before a 
competition and to allow the body to recover from the training. 
NUTRITION - DATA ENTRY 

Figure 1 4 shows a diet web page 1 400 which includes a field 1 40 1 . The diet web page 1 400 
is similar to the web page 1 000 and allows the user to enter information about the foods he has eaten 
20 during the previous week. The system 101 requires the user to enter information for at least five of 
the preceding seven days in order to perform a meaningful assessment of the user's diet. 

By selecting one of seven buttons 1402, the user can select one of the preceding days. 

Figure 15 shows a web page 1500 that allows the user to enter dietary information for a 
particular day. As shown, the web page 1 500 is for the date of 6 January 2004. The web page 1 500 
25 includes pull down menu 1 5 0 1 to allow the user to select a dietary group from : (i) bread and cereals, 
(ii) fast foods, (iii) dairy, (iv) drinks, (v) fats, oils and sugars, (vi) fruit and vegetables and (vii) 
protein. 

A pull down menu 1502 allows the user to select a particular foodstuff from the dietary 
group. Examples of foodstuffs are tuna fish, Caesar salad and bread pudding. A pull down menu 
30 1 503 allows the user to select a portion size. 

By using the pull down menus 1501-1503, the user can enter his dietary intake for the 
preceding week. The database 1 10 stores information listing the nutritional values of the various 
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foodstuffs. For example, lOOg (grams) of tuna fish may be listed as providing 23g of protein, 0.2g 
of carbohydrate, 13g of unsaturated fat and 4g of saturated fat. 

Once the user has entered his dietary intake for the preceding week, he can use a button 1403 
of the web page 1400 to view an assessment of his diet regarding his needs. The server 101 uses 
5 information stored in the database 1 10, in conjunction with the information provided by the user 
regarding both the types and quantity of food and drinks he has consumed, to determine how much 
protein, carbohydrate and fat he has obtained from his diet. 

When a user has entered data for a week, this data is stored in the database 1 10 for later 
retrieval. Usually, the user will enter information every week concerning his food intake for the 
10 previous week. The data stored in the database 1 10 avoids the user having to enter the data from 
scratch each week. Instead, the user can cause the server 101 to retrieve the data from the database 
1 1 0 and display the data at a web page (not shown) at the user's PC 1 02. The user then indicates the 
changes compared to his diet for the previous week. This feature provides the advantage that the 
user can more readily enter his food intake. For example, if the user eats the same foodstuffs each 
15 week then he will not need to enter any information but will merely need to inform the server 101 
that his diet was the same as the previous week. 

Once the server 101 has determined the user's food intake, this can be displayed at a web 
page 1600. 

NUTRITION - ASSESSMENT 
20 Figure 16 shows a nutrition assessment web page 1600 which displays at a field 1601 the 

daily energy requirement of the user as calculated on the basis of the information provided by the 
user at web pages 1000 and 1 100. The field 1601 displays the same numerical value for the user's 
daily energy requirement as was calculated by the server 101 for display at the field 1201 of web 
page 1200. 

25 A field 1602 of the calorific assessment web page 1600 displays an analysis of the calorific 

value of the foodstuffs and drinks that the user has consumed during the seven previous days. The 
analysis is performed by the server 1 0 1 on the basis of the dietary information entered by the user at 
web pages 1400 and 1500. In this embodiment, the server 101 analyses the calories provided by the 
user's diet in four categories: (i) protein, (ii) saturated fat, (iii) unsaturated fat and (iv) saturated fat. 

30 For example, if the various parts of the user's diet together contain 1 OOg of protein each day then he 
will receive 350kCal each day from protein alone. As shown at Figure 16, here the field 1602 
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indicates that the user is obtaining an average of 448kCal a day from protein, 5 15kCal a day from 
carbohydrates, 231kCal a day from unsaturated fat and 57kCal a day from saturated fat. 

The field 1 602 also provides an indication to the user of the suitability of his dietary food and 
drink intake. As shown at Figure 16, here the field 1602 indicates that the user's is obtaining the 
5 correct amount of calories from his protein intake, but is receiving too many calories from his 
unsaturated fat intake. The suitability of the user's calorific intake in the four categories listed above 
is determined by the server 101. The server 101 analyses the user's food intake for the previous 
seven days and compares this with a profile that is stored in the database 1 10. Depending on the 
results of the comparison, the server 101 causes the field 1602 at the user's PC to display whether 
10 the user is obtaining the correct number of calories from the four categories of his diet. 

The server 101 calculates the user's energy requirement by comparing the user's calorific 
intake with the user's calorific expenditure displayed at the field 1201 . In this embodiment, if the 
user's energy intake is within 10% of his energy expenditure then "OK" is displayed at the field 
1602, to indicate to the user that his energy intake is satisfactory. If his energy intake is less than 
1 5 90% or more than 1 1 0% of his energy expenditure then the field 1 602 displays "too low" or 'too 
high", respectively. If his energy intake is less than 70% of more than 130% of his energy 
expenditure then the field 1 602 displays "far too low" or "far too high", respectively. 

In this embodiment, the server 101 calculates the number of calories that the user should be 
receiving from saturated fats and from unsaturated fats, as a percentage of his energy expenditure. 
20 There is no lower limit for saturated fats. For saturated fats, "too high" is set at 10%, and "far too 
high" is set at 1 5% of the user's energy intake. For saturated fats, the lower limits are 1 5% and 1 7% 
and the upper limits 22% and 25%. 

In this embodiment the server 101 calculates the user's protein requirements and 
carbohydrate requirements on the basis of the user's weight in kilograms (kg). If the user consumes 
25 less than 1 .20g of protein per kg of his bodyweight then the field 1 602 indicates "too little". Thus a 
70kg user should consume a total of between 84g and 105g of protein a day, for example by eating 
41 lg of tuna fish (which contains 24g of protein per lOOg) each day. If he consumes less than 0.70g 
per kg per day, the field 1 602 will display "far too little". The upper limits for protein are 1 .50g and 
2.00g for "too much" and "far too much", respectively. For carbohydrates, the lower limits are 
30 2.00g and 4.00g and the upper limits are 7.00g and lO.OOg. 

The upper and lower limits for protein, carbohydrate, unsaturated fat and saturated fat are 
stored as predetermined values in the database 1 10. Each time that the web page 1600 is displayed, 
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the server 101 retrieves the predetermined values and calculates, on the basis of the user's physical 
activities, his dietary intake and his weight, whether he has been consuming the correct amounts and 
correct proportions of the various food categories. 
NUTRITION - DIETARY ASSESSMENT 
5 Figure 17 shows a web page 1700 that the user can select for display if the field 1602 

indicates that he has not been eating appropriate foods. The web page 1 700 includes a protein field 
1 70 1 , a carbohydrate field 1 702, a fat field 1 703, a fluids field 1 704 and a fruit and vegetables field 
1705. 

The protein, carbohydrates and fat fields 1 70 1 - 1 703 show both the user 5 s actual consumption 

10 1701a, 1702a, 1703a for the respective food category and the user's target consumption 1701b, 
1 702b, 1 703b for the food category. If the user needs to change his daily food intake then the fields 
1701-1703 also indicate to him how large a change he needs to make. 

The web page 1 700 also includes a field 1 704 that provides information regarding the user's 
fluid intake, and a field 1705 that provides information regarding the user's fruit and vegetable 

1 5 consumption. For the field 1 704, the server 1 0 1 determines whether the user has been consuming 
sufficient quantities of fluids (i.e., water). If the user's daily intake of water is outside the ranged! 
(liters) to 51, then the field 1704 indicates that user needs to drink more or less water. For the field 
1705, the server 101 calculates the user's intake of fruit and vegetable based on the user's dietary 
intake as entered at web page 1 500. For example, Caesar salad would count towards the user's fruit 

20 and vegetable intake whereas tuna fish would not be regarded by the server 101 as forming part of 
the user's required fruit and vegetable intake. The server 101 consults the database 110 to assess the 
relevance of the foods towards the fruit and vegetable intake. For example, in this embodiment the 
database 110 stores predetermined information indicating that lOOg of Caesar salad counts as 50g 
towards the user's fruit and vegetable intake quota. 

25 TRAINING SCHEDULE - COARSE 

Figure 18 shows a web page 1800,as seen by the user, that the user can use to generate a 
personalized training schedule. The web page 1 800 allows the user to indicate, at a coarse level, the 
time slots that he will have available for training during the following seven days. Here, the web 
page 1 800 represents dates ranging from "tomorrow" (7 January 2004) through to 1 3 January 2004. 

30 The web page 1 800 includes a field 1 80 1 that the user can use to indicate his availability for morning 
training sessions, both for skating training and fitness training. A field 1802 allows the user to 
indicate his availability for afternoon skating and fitness training sessions. As shown at Figure 18, 
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here the user has indicated that he can perform ice skating training on the mornings of 7 January 
2004 and 1 1 January 2004, and in the afternoons of 9 January 2004 and 1 3 January 2004. Although 
the web page 1 800 shown at Figure 1 8 does not indicate that the user will be performing any fitness 
training during the week, it is expected that in normal use of the system 100 he would perform a 
5 mixture of both ice skating training and fitness training. 

Once the user has indicated his availability, he can click a button 1 803 on the web page 1 800. 
This causes the server 1 01 to interact with the database 1 1 0 to suggest a proposed training schedule 
for review by the user. 

The proposed training schedule is devised by the server 101 taking into account the user's 

10 fitness and his weaknesses. Although at Figure 4 seven different measures of the user's fitness are 
shown, in this embodiment the server 101 lumps these into four categories: (i) flexibility, (ii) 
cardiovascular, (iii) strength and (iv) core stability. In this embodiment, flexibility is determined 
solely on the basis of the user's sit and reach capability. Cardiovascular is determined on the basis 
of the user's one mile run time and shuttles ability; in this embodiment the one mile run time and the 

15 shuttles ability are given equal weighting. Strength is determined on the basis of the user's long 
jump distance and high jump height. Core stability is determined on the basis of the user's situps 
score and pushups score. In this embodiment, the factors making up the strength and core stability 
categories are also given equal weighting. 

For example, referring to Figure 4, the user has scores of 1 00% except for pushups which is 

20 58%, situps 68% and shuttles 72%. Thus in the core stability category, the user has a score of (68% 
+ 58%)/2 = 63%o. In the cardiovascular category, the use has a score of (100% + 72%)/200 = 86%. 
Thus of all the four categories, the user's core stability score is his weakest, while his cardiovascular 
is his second weakest as he has 100% in the other categories (strength and flexibility). 

Thus for this user, the server 101 proposes a training schedule that concentrates primarily on 

25 improving the user ' s core stability score. The server 1 0 1 also attempts, with secondary importance, 
to develop the user's cardiovascular score. 

Although for the web page 1800 at Figure 18 the user had not selected any fitness training 
sessions, suppose that the user had selected four fitness training sessions. The server 101 allocates 
the majority of the training sessions to the primary weakness, in this case core stability, and the 

30 remaining training sessions (if any) to the secondary weakness, in this case cardiovascular. Here the 
user can attend four training sessions and therefore three of these are devoted to situps with the 
remaining session being devoted to cardiovascular exercises. If the user had selected three or fewer 
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training sessions then they would all be devoted to core stability. On the other hand, if the user had 
selected five or more training sessions then the server 101 would devote one of the five training 
sessions to a tertiary weakness. 

Once the server 101 has determined what type(s) of training are required for the training 
5 schedule, the server 101 then determines the intensity of training required. 

In the case of core stability, the intensity is determined on the basis of the user's pushups and 
situps score. For example, here the user is capable of performing 45 pushups in one minute and 30 
situps in one minute. The server 101 determines the total number of pushups and situps that the user 
should perform during a training slot by multiplying the user's pushups and situps scores by 1 .6, to 

10 arrive at 72 and 48, respectively. (Note that as is discussed further below, the multiplier may be 
reduced from 1.6 to 1.0 during the week immediately before a competition.) The server 101 then 
separates the total number into groups that will be performed by the user at different times within a 
training slot. The reason that the total number is split up is to ensure that the user is overloaded 
during the training but without becoming excessively overloaded. Here, the user's pushups and 

1 5 situps scores are at the limit of the user's capability and therefore he would not be able to complete 
72 pushups (or 48 situps) in one go. Distributing the total number at different parts of the training 
session ensures that the user derives maximum training benefit. ' 

In the case of cardiovascular, the intensity is determined on the basis of the user's deemed 
maximum achievable heart rate. In this embodiment, the user's maximum achievable heart rate is 

20 estimated by subtracting the user's age from 220. Thus a 20 year old user would be deemed to be 
capable of achieving a heart rate of 200 beats per minute at maximum exertion. To improve the 
user's cardiovascular score, he is required to perform an activity such as swimming, running, cycling 
or skating such that his heart rate is maintained at a specified proportion of his maximum achievable 
heart rate. The specified proportion will depend on the user's fitness level. In this embodiment, a 

25 relatively unfit user will be required to increase his heart rate to 55% of his maximum achievable 
heart rate. On the other hand, an athlete of high fitness would be required to maintain his heart rate 
at 85% of his maximum achievable score. 
TRAINING SCHEDULE - FINE 

Once the server 101 has determined a proposed training schedule for the user, the server 101 

30 causes the user's PC 102 to display a web page 1900, as shown at Figure 19. The web page 1900 
allows the user to review the proposed training schedule and refine the proposed training schedule 
until it fits in with his diary. Thus there is a two stage procedure by which the user interactively 
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causes the server 101 to generate a training program that is tailored to the user. Firstly, the user uses 
the web page 1800 to inform the server 101 at a coarse level of the training that he can perform 
during the following week. Secondly, the user uses the web page 1900 to refine the proposed 
training program so that it fits in with his other activities (such as leisure and work) during the 
5 following week. An advantage of this two stage procedure is that the proposed training schedule 
will meet the basic requirements of the user. By contrast, a single stage procedure would run the risk 
of providing a poor user interface as the proposed training schedule would not take into account the 
user's other activities during the week (and would then require the user to extensively edit the 
proposed training schedule, for example by editing and moving a proposed a training slot from a day 

10 originally proposed to different day that does not clash with say, work). 

The web page 1900 includes a field 1901 that represents each of the 24 hours of each of the 
following seven days. Figure 19 shows days in the range 8 January 2004 to 14 January 2004. Each 
hour is divided into 15 minutes intervals. The field 1901 uses color coding to represent the types of 
activity allocated to the field 1901 . A field 1902 provides a key to the user and explains the color 

15 codes. The field 1902 shows the colors that are used for the following activities: (i) nutrition, (ii) 
on-ice training, (iii) fitness, (iv) competition, (v) leisure, (vi) work, (vii) fitness test, (viii), "other" 
and (ix) sleep. 

The web page 1900 provides a graphical user interface that allows the user to inform the 
server 101 of the detailed timings of his weekly schedule. For example, suppose the proposed 
20 training schedule specifies a training slot of one hour on 1 1 January 2004 from 6am to 7am. In this 
example the server 101 knows, from the information entered by the user at web page 1 800, that the 
user will be able to train on 1 1 January 2004. However, the server 1 0 1 does not know the exact time 
that the user is available for training. 

The user uses a field 1903 to inform the server that he can actually perform the training 
25 between 7.45am and 8.45am on that particular day (see Figure 1 9). The server 101 stores the actual 
times (that the user will be available for training) in the database 110. This allows the user to consult 
the database 1 10 via the server 101 at any time and review or check his schedule. 

If the user has entered the times and dates of forthcoming competitions using the 
competitions region 202 of the web page 200 then, if any competitions are due to occur during the 
30 next seven days, the competition(s) are displayed in the appropriate time slots of the field 1 901 . As 
was mentioned earlier, the server 101 can "taper off the intensity of training in the run up to a 
competition, in order to minimize the risk of injury to the user before the competition. 
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INJURIES 

In case the user sustains an injury, the system 101 allows the user to enter information 
regarding the injury (or injuries). Figure 20 shows a web page 2000 that allows the user to enter 
injury information. The web page 2000 includes an icon 200 1 that represents the front of the body (a 
5 button 2002 allows the user to select the back of the body in case the injury is at the rear of the user). 
The user selects the icon 2001 to cause a web page 2100 to be displayed. 

Figure 21 shows the web page 2100. The web page 2100 allows the user to enter detailed 
information concerning the location of an injury and the severity of an injury. An icon 2101 allows 
the user to select a region of the body. Fields 2102 and 2103 allow the user to specify the exact 
10 locations and severity of injuries, respectively. A field 2104 allows the user to specify the date of 
the injury. The server 101 then stores this information in the database 1 10. 

The field 2103 allows the user to select one of several predetermined categories of severity, 
for example mild (i.e., pain is not intense and ceases immediately when physical activity ceases) or 
severe (pain occurs immediately upon any activity using the injured area and remain for 12-24 hours 
15 after the activity ceases). 

If the user has any injuries that are more serious than "mild" then the server 1 0 1 prohibits all 
training when proposing a training schedule for the user at web pages 1 800 and 1 900. • 

A benefit of storing the injury information in the database 1 1 0 is that the database 1 1 0 can be 
interrogated to determined the injury history of the user. For example, by maintaining the injury 
20 profile over the course of several years, patterns in the injuries sustained can be discerned. Some 
users may have technique deficiencies or muscular imbalance, resulting in an excess of injuries on 
one side of the body. 
COACH 

The system allows coaches to be associated with users. As far as the system is concerned, a 
25 coach is similar to a user in that he also has a user coach also has an account and a password for 
accessing the system. 

A difference between a coach and a user is that the coach monitors the performance of his 
trainees. As the database 1 10 stores information associated with each user, the coach can use the 
server 101 to interrogate the database 110, and thus can monitor the progress of his trainees. 
30 Before a coach can access information concerning a user, that user must first inform the 

server 101 that the particular coach is authorized to view his performance information. This security 
feature prevents coaches from monitoring users that they are not training (e.g. competing users). 
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DATABASE STRUCTURE 

Figures 22a, 22b, 22c and 22d when assembled as shown in Figure 22 show a block diagram 
2200 of some of the major structures within the database 110. In this embodiment, the data that 
comprises the database 1 10 is stored on a hard disk drive (not shown). 
5 As can be seen, in this embodiment the database 1 10 is a relational database having tables. 

Each table comprises one or more records. Each record comprises one or more fields. At least one 
database key is associated with each table. All tables are indexed by a primary key. The primary 
key allows the records of a particular table to be uniquely specified for read or write accesses. In 
some tables, one or more of the fields will be a foreign key. When a table contains foreign keys, that 
10 table can index records stored in a related table. 

A table 2201 stores basic information concerning a user. The user is uniquely identified by a 
key "user_id" which allows users having identical names to be distinguished. This table also stores 
the date of birth of the user, his/her gender, residence address and email address. The user_id is the 
primary key of many of the tables that make up the database 110. 
1 5 The system uses passwords to allows users to authenticate themselves to the system. A table 

2202 stores each user's password. 

A table 2203 relates each user, by his userjd, to his respective coach (if any). Although it is 
not essential that a user has a coach, it is expected that many users would have a coach to train them. : 
Each coach has a coach_id which uniquely identifies that coach, even if several coaches have the 
20 same name. To ensure that only the intended coach is able to view the user's profile, each coach is 
allocated a "pin_number". When a user and coach meet, for example during a coaching session, the 
coach communicates his pin_number to the user. The user can then enter the coach_id of his coach 
into the system 100, which stores the pin_number in the table 2204. 

A table 2205 stores basic information concerning a user such as the user's height and weight. 
25 A table 2206 stores financial information for the user, for example a transaction_id to 

identify a particular credit card transaction. A table 2207 stores information concerning the user's 
account, for example the date of activation of the account and the date of expiry of the account. 

A table 2208 stores, for a variety of different data, the date that an update for the data is next 
required. In this embodiment the table 2208 stores the update dates of core stability, strength, 
30 growth, a mood profile of the user, goals for setting by the user (see table 221 1), and the user's 
height and weight. Each time that the user enters data for these data types, the server 101 calculates 
the due date of the next update. For example, if an 14 year old male user entered height information 
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on 14 January 2004 then the due date for updating his height and weight information would be 14 
January 4004 plus 2 weeks, i.e. 28 January 2004. The value of 28 January 2004 would be stored in 
the table 2208 for his height and weight information. Whenever the user logs on to the server 101 , 
the server 101 compares the actual calendar date to the dates specified by the table 2208 for updates 
5 and, if an update is required, informs the user. The use of the table 2208 increases the performance 
of the system 100. This is because the server 101 only needs to check the dates in the table 2208 
against the calendar date. 

By contrast, if, in an alternative embodiment, the system did not use the table 2208, it would 
be necessary, each time the user logged on to the server 101, for the server 101 to interrogate a 

1 0 variety of tables of the database (i. e. , each table where information such as core stability was stored) 
as rather than storing the update dates centrally in a table 2208, the update dates would be scattered 
amongst a variety of tables of the database 110. Such an embodiment would require more 
processing time to access the various tables, due to the need for the server 101 to traverse the 
database hierarchy. In some situations, the increased processing time would lead to unacceptable 

1 5 delays while the user waited for the server 1 01 to interrogate the various tables of the database 1 1 0. 

A table 2209 associates the user Jd, a "goal_session_id", a creation date for the session and a 
flag to indicate whether or not the coach (if any) is allowed to view the data associated with a 
particular goal_session_id. The use of a goal_session_id allows the process whereby a user enters 
his dream, outcome and process goals (see web pages 500-900) to be broken down into separate 

20 steps if the user prefers. Typically, it will take about 20 minutes for a user to analyze his goals in 
conjunction with the web pages shown at web pages 500-900. Without the use of the 
goal_session_id, the user would have to complete the goal entering process in a single session. (If 
the user did not complete the session, he would have to enter all of the data all over again in a later 
session). 

25 The use of a goal_session_id allows the user to enter a portion of the required data. The data 

entered is then stored in the database 1 10 and is associated with the goal_session_id. When the user 
is ready to enter more of the required data, the data previously entered is retrieved from the database 
110 and is used to continue the goal setting process. 

A table 22 1 0 stores the data entered during a particular session and associates the data with a 

30 goal_session_id. 

A table 2211 stores the results of user's goal assessments. The table 2211 stores a 
"psych_perf_id" which is used to relate table 2211 to a table 2212. The table 2211 stores 
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information including the user's assessment of his own abilities, the coach's assessment of the user's 
abilities, and text entered by the user as part of his assessment of his abilities. The inventors of the 
present application have realized that a significant problem during sports training can be when the 
user and the coach have different assessments of the user's abilities. The fact that the table 221 1 
5 stores both the user's self assessment and the coach's assessment allows these two assessments to be 
compared for discrepancies. 

The table 2212 stores information regarding the user's short term goals. The table 2212 not 
only stores specific goals but also allows the user to enter when a specific goal has been completed. 
In addition, the table 22 1 2 includes a field specifying a review period for the short term goals. This 
1 0 ensures that the user will be prompted to periodically review his short term goals. An example of a 
short term goal for a user is that of ensuring that he maintains "clean heels" during an ice skating 
maneuver. 

A table 2213 associates userjds with "competition_id"s. A competition_id is an identifier 
for various competitions. The competition^ is used as a key for an event table 22 1 4. Each event in 
15 the event table 2214 is identified by its name, start and end dates and region. The compefition_id 
key is a composite key and comprises a plurality of the fields of the various records in the table 
2214. This allows, for example, annual competitions held on different years to be distinguished on 
the basis of their dates. 

A table 22 1 5 stores an analysis of the user's abilities. The table 22 1 5 stores the results of an 
20 analysis that compares the user fitness rating with his goals. In effect, the table 22 1 5 acts as a cache 
to store the results of the analysis. 

A table 2216 stores the dietary history of the user(s). For each user, the table 2216 records 
the type of food and drink that the user consumed, the number of portions, which meal the food was 
eaten for and the date that the food was eaten. The table 22 1 6 includes a field "food Jype _id" which 
25 is used as a key for another table, table 2217. Table 2217 is itself a database of a variety of foods 
and drinks, and associates the nutritional breakdown of each type of food with the respective 
food_type_id of the foods. 

A table 22 1 8 stores data for custom foodstuffs that are not by default included in the database 
110. When a user eats a type of food or drink that is not included in the food table 22 1 7, he has the 
30 choice of (i) entering nutritional data for the food as a one-off or (ii) creating a new type of food 
category and entering the nutritional data for that food. The table 22 1 8 has two keys, the userjd and 
"custom_food_id". The custom_food_id has the same function as the food_type_id of table 2217 
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but is personal to the user. Thus any user can select a foodstuff in the default food table 22 1 7; on the 
other hand, a user can only enter custom foodstuffs that he has entered. As the data entered for a 
custom foodstuff is entered by the user, the authenticity of such data cannot be regarded as high as 
that for the foodstuff in the table 22 1 7. Ensuring that a user can only select the custom foodstuffs 
5 that he has himself entered prevents one user from entering a foodstuff that has been incorrectly 
entered by another user. The table 22 1 8 allows users to, in effect, set up a cache for food items that 
they frequently consume but that are not in the table 22 1 7. Tables 22 1 7 and 22 1 8 store information 
for foodstuffs such as their sugar content, protein content, portion size, calcium content and type of 
food category. 

10 A table 2219 uses "injury_id" as a unique identifier for each injury that any user sustains. 

The table 2219 also stores the userjd together with details on which side of the body the injury 
occurred and the number of injuries that have been sustained on that side. The table 22 1 9 also stores 
a foreign key "injury_status_id" to a table 2220 and a foreign key "injury_kb_id" to table 2221. 
Table 2220 records the status of an injury and associates this with the injury_id and a rating of the 

15 severity of the injury. Table 2221 stores a knowledge base that may be consulted by the user to 
obtain detailed information about an injury. Table 2221 includes information about the location of 
an injury, the type of injury and advice concerning the various types of injuries. 

A table 2222 stores the activity schedule displayed by web page 1900. The table key for 
table 2222 is "schedule Jd" which is used to distinguish the various schedules that will be generated 

20 by the system 100. The table 2222 associates the schedule_id with the userjd and also includes 
information regarding the dates of activities, the start and end times, the type of activity that is to be 
performed during a training slot and the energy that is predicted to be expended by the user during a 
training slot if he trains to the specified intensity and for the specified duration. 

A table 2223 stores the preliminary schedules entered into web page 1800. The key for this 

25 table is "schedule^sessionjd" which associates the date of a particular session, whether the user will 
be performing morning and/or afternoon on-ice training and whether the user will be performing 
morning and/or afternoon fitness training. 

A table 2224 relates the various userjds to a "skating_level_id'\ There are various 
skatingjeveljds which relate a specific ice skating skill level. A table 2225 relates the various 

30 skating Jevel_ids to a description of what is expected of the user at each skatingJeveMd. When the 
user creates an account, he reads the descriptions provided in table 2225 so that he can choose a 
skating_level_id that is appropriate to his skill level. 
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A table 2226 is concerned with the activity assessment for a user. The fields of the table 
2226 include the duration of an activity, an "activity_id", the date of the activity, the start time of the 
activity and the userjd. The key for table 2226 is a combination of the date, start time and user_id. 
The activity assessment table 2226 records the actual activity of the user as opposed to the intended 
activity stored in table 2222. The activity_id is used as a key for a table 2227 and a table 2228. 

Table 2227 is keyed by activity_id and associates the various activity_ids with descriptions 
of the activity. Table 2228 is also keyed by activity_id and provides a predetermined breakdown of 
an activity for various physical categories. In this embodiment, the key activity_id indexes records 
that contain six fields. The six fields are cardiovascular, core strength, upper body strength, lower 
body strength, flexibility and local muscular endurance. 

An activity analysis table 2229 contains a breakdown of a user's physical activity. For each 
userjd, the table 2229 records the dates of exercise and the contributions of the exercise to the 
user's requirements. Here, the table 2229 records the contribution of a physical activity in the 
cardiovascular, core strength, upper body strength, lower body strength, flexibility and local 
muscular endurance categories. The table 2229 also records the user's energy expenditure on each 
date that resulted from the physical activity. . : - 

A table 2230 records the scores of users' fitness assessments. The key for table 2230 is 
"fitness_assessment_score_id" which uniquely identifies each fitness assessment. Other fields in the 
table 2230 are the userjd; the test score(s) of the user for shuttles, the sit and reach test etc; the 
percentage rating of the user's scores compared to his expected rating; and a record of the date when 
his fitness score was last updated. 

A table 2231 is used to relate users' shuttle test scores to their bodies' ml0 2 /kg capability, 
where ml0 2 /kg is a measure of the users' ability to transport oxygen, measured in ml of 0 2 , around 
his body per kg of body weight. Given the level at which a user completed the shuttle test (i.e. the 
period between successive "bleeps") and the number of shuttles completed at the final level, a 
formula is used to calculate the expected ml02/kg rating of the user. In this embodiment the 
formula has been developed by Loughborough University of Great Britain and has been found to 
give a good indication of the user's ml0 2 /kg score. 

A table 2232 is used to relate the fitness assessment scores of a user to target values for each 
of the categories of measurement. In this embodiment the table 2232 has target values that would be 
expected of an elite skater for each of the categories in the fitness assessment test (shuttles, 1 mile 
run, sit and reach etc.). Table 2232 has expected scores for both males and females of ages 8-60. 
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Thus the expected fitness assessment scores of, for example, a 23 year old female ice skater are 
determined by looking up the most appropriate fitness assessment scores from the table 22322. Note 
that the table 2232 also includes the mlC^/kg expected of a user, again indexed by age and gender. 
Although the fitness tests do not directly measure the ml0 2 /kg ability of a user, this can be inferred 
5 as was explained for table 223 1 above and so is included in the table 2232. 
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DESCRIPTION OF A SECOND EMBODIMENT 

At Figure 23 there can be seen a server 10 with accompanying computer terminal 11. The 
server 10 is connected via a telecommunication network, e.g. the Internet, to remotely located 
personal computers 12,13, and 1 4. In the example given the server 1 0 has a website which can be 
5 accessed via the Internet and users of the system use web-browser software on the personal 
computers 12, 13 and 14 to access the website hosted by the server 10. 

On the server 10 there is maintained a database which for each of the plurality of sports 
maintains a record of an idealized physiological profile for the sport. 

To obtain a meaningful physiological profile the second embodiment can use items such as: 
Maximum capacity to transport oxygen to tissues(V02max), 

% of V0 2m ax that may be maintained without accumulation of lactate (OBLA), 

Maximum strength measured as the greatest weight that can be lifted just once (1-RM), 

Maximum power measured as the work output in a unit of time (POW) 

Core strength measured as the maximum number of sit-ups (COR1), push-ups(COR2) and 
crunchies (COR3) that can be performed without rest. 

Local muscular endurance (LME). 

As an example, an elite marathon runner is likely to have relatively high V02max, very high 
OBLA, low 1 -RM, low POW, low COR1 , low COR2, low COR3 and low LME when compared to a 
gymnast, or a figure skater. 
20 Similarly, the marathon runner will have a different psychological, nutritional and injury 

profile from the gymnast or an overweight person due to the dissimilar demands of the respective 
sports and goals. 

In the system, the stored idealized physiological profile for a sport is used to determine where 
the weakness in a particular athlete lies, and an ongoing training and assessment schedule is 
25 generated. 

When a sports person first accesses the website hosted by the server 10 he/she is asked to 
supply the following information (hypothetical figures are given as illustrations): 
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X 
X 
X 
X 
X 



15 



X 



Variable 


Athlete 


Gender 


Male 


Age 


24 


Height (m) 


1.76 


Resting Heart rate (bpm) 


34 


Weight (kg) 


76 


Sport 


Long distance runner (10 km+) 



The server 10 then retrieves from the database the idealized physiological profile for the 
sport selected by the sports person, in this case long distance running. The retrieved measurements 
of the idealized profile are then scaled having regard to the body weight of the sports person, the 
gender and age. The resulting figures for these hypothetical examples are given in the table below. 



Variable 


Idealized Measurements 


V0 2m ax(ml0 2 /kg) 


80 


OBLA (% V0 2ma x) 


65 


1-RM (kg) 


385 


Aerobic Power (W/kg) 


28 


Core strength 


100 


LME (mmol/1) 


2.25 



The sports person is prompted by a visual display on the local personal computer to input 
measurements of his/her Vo 2m ax, OBLA, 1-RM, POW, COR1, COR2, COR3 and LME. The server 
1 0 then calculates from the input POW and weight information an aerobic power figure and from the 
input COR1, COR2 and COR3 figures a core strength figure. Then the server 10 makes a 
comparison between the current physiological profile of the sports person and the idealized 
physiological profile for the selected sport (normalized by weight, age and gender) as illustrated by 
the table below. 
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Variable 


Optimum 
value 


Actual 
Value 


% difference 


V0 2m ax (ml/kg) 


80 


60 


75 


OBLA 


65 


60 


92 


Aerobic Power (W/kg) 


26 


21.7 


83.5 


1-RM squat 


85kg 


75 


88 


Core strength 


100 


95 


95 


LME 


2.25 


2.30 


102.2 



From the comparison the system can establish that the most important area to improve for 
this particular athlete is V0 2 max. The system would now recommend a training regime to maximize 
the key component. 

Optimizing the V0 2m ax can be achieved by establishing a training regime that has a high 
5 volume and relatively low intensity. For running, the scheme follows that shown below (which 
would be relayed to the sports person as information displayed on the video display unit of his/her 
personal computer and printed locally by the sports person). 



Factor (component) 


Lower 
Value 


Upper Value 


Sessions/week (volume) 


3 


4 


Distance % of competition (volume) 


150 


180 


Intensity % of maximal heart reserve 
(intensity) 


65 


75 



The volume of training is evaluated as shown: 

Volume™ = Sessions * Distance, where 
1 0 Sessions = number of sessions per week and distance = distance run in each session. 

In the hypothetical example, the athlete is recommended to complete 3 training sessions with 
distance = 150 % of competition distance (i.e., 15 km). There should be 2 days rest between 
training. 
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The intensity is evaluated as a percentage of Maximum output from following the Karvonen 
formula: 

THR = HR r est + INT * (HIW HR^t), where 
THR = training heart rate 
5 INT = Intensity percentage/ 100 (e.g. 80 % = 0.8) 

Hl^est = Resting heart rate and 

HRm ax = Maximal heart rate (this is either available from a maximal test or can be estimated 
from 220- age (years)) 

For our athlete, the THR = 34 + 0.70 * ((220- 24) - 34) = 163 beats/minute 
10 The actual training run can be done within a band of 5 beats/minute either side of THR (at 

this level of athlete, one would expect that a heart rate monitor is used). 

In a variation of the system the sports person is assessed for symptoms of overtraining, and 
research has shown that psychological assessment tools such as a Profile of Mood States (POMS) 
can be used to indicate risk of overtraining. 
1 5 Mood data for the sports person are obtained by appropriate questions relayed via the local 

personal computer. Categories, are established as shown in the table below. The base value 
represents the average value from all of the data obtained during the off-season. For details of the 
specific method for eliciting data from a profile ofmood states questionnaire see Terryetal. (1999). 



Mood dimension 


Base Value 


Last session 
value 


Anger 


4 


6 


Tension 


5 


8 


Vigor 


9 


4 


Depression 


1 


5 


Fatigue 


2 


7 


Total 


21 


30 



The system compares current POMS scores to historical base values (obtained during an off- 
20 season). Two tests are used: 

Test 1 : is the current total POMS score more than 50% above reference values? 
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In our case, 21 + 50% = 31 .5 indicating that it is not. 

Test 2: Is the current measure of Fatigue higher than current measure for Vigor? 
In our case this is true. 

The overtraining risk is used to modify the proposed training schedule by reducing the 
5 recommended training volumes and training intensities by the percentage figures below (overtraining 
risk is 0% if the answers to both of the above questions are "no", 50% if one answer is "yes" and one 
is "no" and 100% if both answers are "yes"). 



Overtraining 
Risk % 


Training 
Volume 


Training 
Intensity 


0 


0 


0 


50 


15 


20 


100 


60 


50 
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ALTERNATIVE EMBODIMENTS 

The training systems have been described above in terms of a single user. In alternative 
embodiments the systems may be used for a plurality of different users. In this case, each user is 
allocated a respective user_id when he/she creates an account with the server 101. 
5 The training systems described in the first embodiment above comprised a server 101 which 

communicated with a PC 102. In alternative embodiments the server 101 may be connected to a 
plurality of PCs 102. The server 101 may either be connected to any one of a number of different 
PCs 102 or may be simultaneously connected to a plurality of separate PCs 102. In embodiments 
where the server 101 is simultaneously connected to different PCs 102 it is anticipated that each PC 

10 1 02 would be used by a respective user of the system 1 00. 

The training system uses a PC 102 to provide a graphical user interface to a Java program 
which controlled the server 101. The PC 102 was caused to display internet pages using a web 
browser. In an alternative embodiment the server 101 may communicate with dedicated software 
installed on the PC 102. In this alternative embodiment, the dedicated software provides the 

15 graphical user interface. 

The training system uses a server 101 which accesses a database 110. Communication 
between the user's PC 102 and the server 101 is performed using a telecommunications link. In an 
alternative embodiment, software is installed on the PC 1 02 of a user who wishes to use the training 
system. In this alternative embodiment, the software programs the PC 102 to implement the 

20 database 1 10 on the hard disk of the user's PC. An advantage of this embodiment is that the PC 102 
need not communicate with a remote server. However, an advantage of operating the system using a 
central server 101 that is used by all user PCs 102 is that improvements and upgrades may more 
readily be made to the system. For example, when using a server 1 0 1 , it is relatively straightforward 
to update an incorrect database entry for a particular foodstuff In an embodiment where software 

25 for implementing the training system is installed separately on each PC 1 02 then it will be harder to 
update the databases as an updated database entry will need to be sent to each PC 102. 

In some embodiments, dedicated circuitry may be used to implement the required 
functionality of the training system. However, for reason of cost, it is expected that most 
embodiments will include an element of software. Such software may be supplied on a suitable data 

30 carrier such as a floppy disk or a CD-ROM. Alternatively, software may be supplied over a 
telecommunications channel such as the internet. 
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The training system uses circular charts to display the user's fitness assessment and the user's 
goals. In an alternative embodiment other graphical formats may be used instead, for example 
column charts. However the use of circular charts is preferred as this provides an intuitive user 
interface for the user(s). 

5 The training system of the first embodiment enables ice skaters to become more proficient at 

ice skating by helping such users to organize their training schedules, eat appropriate foodstuffs and 
to perform physical activities appropriate to their aims. In an alternative embodiment, the training 
system is be used to train other types of sports persons. For example, in an alternative embodiment 
the database 110 is modified to allow long distance runners to train effectively. In such an 

10 embodiment the database 110 is expanded so that as well as containing information primarily 
dedicated to training ice skater, the database also contains information primarily dedicated to 
training long distance runners. In such an alternative embodiment the tables 2224, 2225 and 2232 
are modified to include predetermined skill level categories for long distance runners together with 
descriptions of the skill categories of long distance runners. Table 2232 would also require 

1 5 modification to be keyed by the type of sport being performed by the user (this is because table 2232 
when described earlier included the scores expected of various ages of elite ice skaters, but did not 
: include the corresponding scores that could be expected of various ages of long distance runners). In 
a yet further alternative embodiment, separate databases are used for different types of users. For 
example, ice skaters may use a first database 110 and long distance runners may use a second 

20 database. In the yet further embodiment, either a common server 101 is used to access the two 
databases, or separate servers are used, one for each database. 

The training system of the first embodiment facilitates ice skaters to become more proficient 
at their sport. In an alternative embodiment, the server 1 01 and a modified database facilitate a user 
to, for example, lose weight. In an yet further embodiment, a modified database facilitates a user to 

25 gain weight (for example body builders who wish to increase their muscle mass). 

In an alternative embodiment of the training system 100 described above, the presence of any 
injuries as entered at the web pages 2000 and 2100 is used to modify the dietary assessment shown 
at web page 1700. Normally, a user's required protein intake was determined on the basis of his 
body weight. When a user has a soft tissue injury he will in some situations require additional 

30 protein in order to allow his body to repair the damage. In an alternative embodiment, the server 101 
is operable to use the database 1 1 0 to determine whether the user has an injury having a severity that 
exceeds a predetermined threshold. If so, then the suggested daily protein intake for the user is 
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increased accordingly. Similarly, in alternative embodiments of the system 100 the user's calcium 
intake in monitored. In the event that the user breaks a bone then his recommended calcium intake is 
increased to facilitate repair of the broken bone. 

In the first preferred embodiment described above, the server 101 compared the user's water 
5 intake with predetermined lower and upper limits of 31 (litres) to 51 of water per day. In that 
embodiment the user was deemed to be an ice skater (i.e. an athlete), due to the level at which the 
user was training. In an alternative embodiment, the user need not be deemed an athlete, in which 
case the server 101 calculates the user's fluid requirements based on the user's body weight. For 
example, the lower limits are set at 25.00ml (milli-litres) and 30.00ml of water perkgofbodyweight 

1 0 per day, and the upper limits are set at 40.00ml and 45 .00ml of water per kg per day. The server 1 0 1 
also increases the deemed water requirement by 500ml for each hour of exercise per day. 

The training system of the first embodiment described above calculated the user's actual 
energy expenditure on the basis of the activities performed by the user and the basal metabolic rate 
of the user. In an alternative embodiment, the user's energy expenditure may be calculated on the 

15 basis of the training program suggested at web page 1900, on the assumption that the user will 
perform the suggested training schedule faithfully and that there will be little or difference between 
the suggested training and the actual training performed by the user. 

The training system of the first embodiment described above used the internet to transfer 
information between users, the server and the payment server. In an alternative embodiment, 

20 dedicated telecommunications links may be used to transfer information. Such dedicated 
telecommunications links may comprise wires or wireless links. 
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